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Abstract 

One of the main drawbacks while implementing the interaction be- 
tween a plant and a supervisor, synthesised by the supervisory control 
theory of Ramadge and Wonham, is the inexact synchronisation. Balemi 
was the first to consider this problem, and the solutions given in his PhD 
thesis were in the domain of automata theory. Our goal is to address the 
issue of inexact synchronisation in a process algebra setting, because we 
get concepts like modularity and abstraction for free, which are useful to 
further analyze the synthesised system. In this paper, we propose four 
methods to check a closed loop system in an asynchronous setting such 
that it is branching bisimilar to the modified (asynchronous) closed loop 
system. We modify a given closed loop system by introducing buffers ei- 
ther in the plant models, the supervisor models, or the output channels of 
both supervisor and plant models, or in the input channels of both super- 
visor and plant models. A notion of desynchronisable closed loop system 
is introduced, which is a class of synchronous closed loop systems such 
that they are branching bisimilar to their corresponding asynchronous 
versions. Finally we study different case studies in an asynchronous set- 
ting and then try to summarise the observations (or conditions) which 
will be helpful in order to formulate a theory of desynchronisable closed 
loop systems. 



1 Introduction 

Supervisory control theory (RW-theory) [10, 11] performs automatic synthesis 
of a supervisor which controls a plant such that a corresponding requirement 
(legal behaviour) is achieved. In control theory terminology, 

• the model which is to be controlled is known as plant, 

• the model which specifies the requirement is known as specification, 

• the model which forces the plant to meet the specification by interacting 
with it is known as supervisor. 

*h.beohar@tue .nl 

tp . J . L . CuijpersOtue.nl 

t j osbSwin . tue . nl 



1 



• the interaction between the plant and the supervisor is known as closed- 
loop behavior. 

The closed loop behaviour in RW-theory is realized by synchronous parallel 
composition. Informally it allows a plant and a supervisor to synchronise on 
common events while other events can happen independently. 

One of the main drawbacks while implementing the interaction between a plant 
and a supervisor, synthesised by the supervisory control theory of Ramadge and 
Wonham, is the inexact synchronization [6]. In practical industrial application 
the interaction between a plant and a supervisor is not synchronous but rather 
asynchronous. Due to the synchronous parallel composition, the interaction 
between the plant and the supervisor is strict. By strict we mean that, either 
plant or supervisor has to wait for the other party while synchronising. To 
overcome this problem it is important to study asynchronous communication 
between the plant and the supervisor where communications are delayed in 
buffers. The choice of buffers depends on the domain of the system to be 
modeled. For instance, to model delay insensitive circuits, a wire (see [9]) could 
be chosen as a buffering mechanism, while to model data-flow networks (see [8]) 
a queue could be used as a buffering mechanism. 

Balemi was the first to consider the inexact synchronisation problem, and the 
solutions given in his PhD thesis [5] were in the domain of automata theory. In 
[5] an input- output interpretation was given between a plant and a supervisor 
and a special delay operator was introduced to model the delay in communica- 
tion. Furthermore, to achieve modularity and abstraction in supervisory control 
theory, the original theory was extended with the concepts of decentralised con- 
trol and partial observation, respectively. These concepts were also developed 
in [5]. 

The disadvantage of a theory to be based on automata theory is that it requires 
development of some special concepts like decentralised control for modularity 
in case of RW-theory. If the theory is based on process algebra, these addi- 
tional concepts can be attained for free. Congruence is one of the key features 
in process algebra which helps in achieving this modularity in system design. 
Modularity is a way of designing a complex system by dividing it into different 
smaller components or subsystems. 

Process algebra is one of the ways in which one can formally specify a system 
behaviour. It contains different constructs such as sequential composition, and 
parallel composition which are used as a basic building block to specify any 
desired behaviour. Apart from this, process algebra also provides modularity 
in system design, and abstraction from behaviour in system analysis. In this 
paper we show that it is possible to redesign a synchronous closed loop system 
in in an asynchronous setting by performing three case studies. Finally, some 
conditions are given which will be helpful in formulating the theory of desyn- 
chronisable closed loop systems. A synchronous closed loop system is called 
desynchronisable iff it is branching bisimilar to a corresponding asynchronous 
closed loop system. 

This report is organized as follows. Section 2 introduces the overall background 
required for this report and consists of three sub-sections with the following de- 
scription. In subsection 2.1 we introduce the formal language in which different 
models (like plant, supervisor or requirement) arc specified. In subsection 2.2 
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we define different buffer models in the specification language. In subsection 2.3 
we give a brief introduction on RW-theory and discuss the relation and some 
results from previous literature with respect to our specification language. In 
section 3 the work-flow for the different case-studies is given. In particular, it 
explains how different tools can be used to refine synchronous communication 
into asynchronous communication. Then the subsections 3.1,3.2, and 3.3 are 
devoted to explain three different case studies. Finally, in section 4 we discuss 
the key conditions which were satisfied by the synchronous closed loop systems 
in the case studies such that they were branching bisimilar to the corresponding 
asynchronous version. 

2 Preliminaries 

2.1 Specification language 

We consider the TCP process algebra [4] as the suitable formalism which will 
be used throughout this paper. This choice is motivated by the following two 
main reasons: 

• One of our goals is to develop this theory and implement it in the current x 
[3] tool set as an extended functionality. We know that TCP as a language 
is a subset of \ an d is simpler to work upon, as the latter has a constructs 
to model hybrid systems while the former is used to model discrete event 
systems only. 

• Previous studies [8, 7, 12] of an asynchronous process composed using 
buffers used failure equivalence. By studying asynchronous system using 
TCP we want to find out whether it is possible to state results in a equiv- 
alence finer than trace or failure equivalence (see [13], for the lattice of 
process equivalences). 

In this paper we use T> and TL to denote finite sets of data elements and channel 
names, respectively. Then for each channel h € TL and each d &T>, assume the 
presence of the following atomic actions: 

• hid : send a data element d at channel h, 

• hid : receive d at channel h, and 

• hid : communicate d at channel h. 

The following notation and definition will be used throughout the paper. The 
complete set of actions is denoted by A where A = {h\d, hid, hid | Vd £ T> A 
V7i G TL}. Then the communication function 7 : A x A — > A is defined for 
all h € TL as j(h\d, hid) — j(h1d, hid) = hid and undefined otherwise. Define 
the blocking set as B = {hid, h\d \ d £ T> A h € TL} and the hiding set as 
X = {hid I d e V A h e TL}. The set of all process terms (denoted by P) is then 
defined by the following grammar: 
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deadlock process 

1 empty process or skip 
hld-P action prefix, where ! £ {?,!,?} 
P + P alternative composition 

P || P parallel composition 

ds (P) action encapsulation, where B C B 

tj(P) abstraction (hiding of actions), where / CI 

Pf(P) renaming of process, where/ : A — > A. 

1Z recursive definition 



The notation 1Z denotes a recursion definition by a set of pairs {Xq = to, ■ ■ ■ , X rn = 
t m } where Xi denotes a recursion variable and U the process term defining it. 
The formal semantics for these operators can be found in [4] . 

Note that in the above definition of process terms it is possible that a process 
may have the same channel for sending and receiving a data element. But 
such processes causes a problem while constructing an asynchronous closed loop 
system from its synchronous counter part. The problem is following: "Suppose 
a process X has hla and Mb in its alphabet. Then the information whether 
h is an input or an output channel is unknown. In this paper we construct 
an asynchronous process by introducing input queues in input channels and 
output queues in output channels. The difference between input and output 
queues will be cleared later in Section 3. Thus, the information whether an 
input or an output queue should be attached with channel h becomes unclear" . 

In order to simplify things, we assume that every process has different channels 
for sending and receiving. Let a(Q) denote the alphabet (see [4]) of a process 
Q. Formally, a process Q £ P is called a simple process iff V/i, d.[h\d £ a(Q) => / 
3d'. [hid' £ ot{Q)} and vice versa. We will work with plants and supervisors 
which are specified as simple processes. 

We now introduce the transition system for a process and for a synchronous 
closed loop system which will be helpful in defining conditions, presented in 
Section 4. A transition system generated by a process X £ P is denoted by 
quintuple Tx = (Qx,^x,QxiAx), where Qx denotes the set of states, -^xQ 
Qx x A x x Q x is the transition relation, q x is the initial state of the process X, 
and Ax C A is the alphabet of X. In this paper we make distinction between 
a transition system for a process and a transition system for synchronous ( or 
asynchronous ) closed loop system. This distinction is based on the alphabet of 
a process, i.e. for a process X which can be used to model a plant or a supervisor 
the alphabet of X should be a set B C B while for a closed loop system Y it 
should be a set I C 1. We use notation Tx for a transition system of a process 
X, Tsc for a synchronous closed loop system. In the next subsection we define 
the different buffer processes which will be used later to study asynchronous 
communication with respect to these different kinds of buffer. 



2.2 Buffer models 

In the previous subsection we defined the syntax of the formal language which 
will be used for specifying plant, supervisor, requirement and buffers. A buffer 
is a process which receives data from another process and stores that data until 
another process reads it. For example, a buffer can be a queue (FIFO), or a 
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stack (LIFO), or a wire, or a bag. Before defining the different buffer processes 
in the above language, we need to define an auxiliary set for channels. This 
is necessary for the conversion of a given synchronous closed system into an 
asynchronous one. So assume that the set H. is closed under 1 , i.e. if h € H 
then also h eH. Then define renaming functions / : H — > H and / : H — > H as 
follows: 

• for any k eH, f(k) = k, 

• for any k eH, /(fc) = k, 

• for fc e H not in the image of /, f(k) = k. 

The subscript notation /j is used to indicate the renaming of input (output) 
channels only. Now we give the formal definition for different types of buffers. 

Definition 2.1. (Queue). Let e denote the empty list. Let £ denote a list 
of data elements. Let e.£, and t;.d denote a list with first element e and last 
element d, respectively. Then, a queue with input channel h g H and output 
channel h = f(h) is specified as follows: 

Q fc (e) = Y. hld - Q ^ ±e ) 

dev 

Q h (td) = h\d-Q h (0 + Y,Me-Qh(e.Z.d) 

eev 

(for every S,eV*,deV.) 
Now define a queue for every set of channels H <ZH: 

Queue H =\\ heH Q h {e) □ 

Definition 2.2. (Stack). A stack with input channel h E H and output channel 
h = f(h) is specified as follows (with parameters as in definition 2.1): 

S h (e) = J2 hld - S »( d - £ ) 

dev 

S h (d4) - h\d-S h (Z) + J2Me-Sh(e.d.$ 

eev 

(for every £_eV*,deV.) 
Now define a stack for every set of channels H CH: 

Stack H =\\ heH S h (e) □ 

Definition 2.3. (Wire). A wire with input channel h £ Ti. and output channel 
h = f(h) is specified as follows (with parameters as in definition 2.1): 

W h (e) = Y, hld - W h{d.e) 

dev 

W h (d) = h\d-W h {d) + Y,h!e-W h {e). 

eev 
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Now define a wire for every set of channels H C H: 

Wire H =\\ heH W h (e) □ 

Definition 2.4. (Bag). Let denote the empty multiset. Let £ denote a 
multiset of data elements . Let £W{e} denote the multiset £ with the multiplicity 
of e increased by 1 and £ fnl {e} denote the multiset £ with the multiplicity of 
e decreased by 1. Then, a bag with input channel h £ H and output channel 
h = f(h) is specified as follows: 

B h (9) = ^Md-B h (9m{d}) 

dev 

B h (0 = £We-B h (£lR){e})+£/i?/-B,,(£W{/» 

e£? /GX> 

(for every £ G £>*, d G X>.) 
Now define a bag for every set of channels H C Ti: 

Bag H =\\ heH B h {$) □ 
2.3 Supervisory control theory 

In this subsection we give a brief introduction to the RW-theory in our setup. 
The basic building block in RW-theory is a deterministic automaton. Plants 
and supervisors are allowed to perform actions or events which are divided 
into two disjoint subsets: controllable events and uncontrollable events, i.e. 
T> = T> c l±l V uc . The idea behind this partition is that the supervisor can enable 
or disable controllable events so that the closed loop behavior is the same as 
the specification under language equivalence. Furthermore, it can observe but 
cannot influence uncontrollable events. 

The two basic differences from the original theory and the current setup are 
following. Firstly, we use processes as the building blocks instead of automata. 
As a consequence we work with finer equivalence than language equivalence. 
Secondly, we follow the input-output interpretation [5] between a plant and a 
supervisor (see Figure 1). In this interpretation the uncontrollable events are 
outputs from a plant to a supervisor and the controllable events are outputs 
from a supervisor to a plant. 

Next we introduce the term deterministic process which will be helpful in defin- 
ing a plant, supervisor and requirement models in our setup. 

Definition 2.5. A process Y G P is called a deterministic process [4] if and 
only if for all states Y of the transition system (generated by the operational 
rules) it holds that Y^UAY^Z^>U = Z, where U, Z e P, and U = Z 
means U and Z are syntactically equivalent. 

The three basic entities in the RW-theory are: a plant, a supervisor, and a 
requirement. A plant is a simple and deterministic process P € P that does 
not contain communication actions. The requirement of determinism is nec- 
essary because the RW-theory (and its synthesis tool TCT [15]) is based only 
on deterministic finite automata. The condition that a plant process does not 
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Figure 1: Context diagram for plant and supervisor. 



contain communication actions can be stated formally as dx(P) iz* P. The 
requirement of the above condition is due to the construction of asynchronous 
processes which is explained in detail in following lines. Buffers (like queues, 
stack, etc) are introduced in both input and output channel. So if communi- 
cation actions (like hid e /) are allowed in the specification of a plant process 
then the information whether the channel h would be an input or an output 
channel of the plant process is unknown. Similarly, a supervisor is a simple and 
deterministic process S GP such that &z(S) ±± S. 

A requirement is a process which specifies the legal interaction that should 
occur while the plant and supervisor are interacting such that a required task 
(for which supervisor is synthesised) is completed. Thus, a requirement is a 
deterministic process E £ P such that 8b(E) ±± E. This condition suggests 
that a requirement process should contain only communication actions in its 
alphabet. 

Now we can state the control problem as follows: find a supervisor S for a given 
plant P and a given requirement E such that, 

d B (P || S) t=f E. 

In this paper we do not consider how the supervisor is computed and rather 
use the solution [15] which provides a closed loop system ds (P || S) strongly 
bisimilar to a requirement E. Then the aim of this paper is to check whether it 
is possible to construct an asynchronous closed loop system (Figure 2(b)) such 
that it is branching bisimilar with its corresponding synchronous closed loop 
system (Figure 2(a)). 



3 Approach 

As already discussed in the introduction section, it is important to study an 
asynchronous interaction between a plant and a supervisor to model an indus- 
trial application. So in this section we first give four ways to construct an 
asynchronous closed loop system from a given synchronous closed loop system. 
Then, a work-flow is presented which explains how different tools can be used 
to refine synchronous communication into asynchronous communication in a 
straightforward and correct way. Later we redesign three case studies in an 
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(a) Synchronous closed loop system. 
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(b) Asynchronous closed loop system. 



Figure 2: Illustration of the research question. 

asynchronous setting based upon the above work-flow and methods which were 
already modelled by the System Engineering group of Eindhoven university of 
technology (TU/e) in the synchronous setting [14]. 

A synchronous closed loop system (Figure 2(a)) can be converted into an asyn- 
chronous one by introducing queues (see Fiugre 2(b)) in following ways: 

Ml. introducing queues between the plant and supervisor process models such 
that the interaction between the plant and queues are hidden (see Fig- 
ure 3(a)). The thick lines are used to indicate the visible interaction and 
thin lines are used to indicate the invisible interaction in Figure 3. 

M2. introducing queues between the plant and the supervisor process models 
such that the interaction between the supervisor and queues are hidden 
(see Figure 3(b)). 

M3. introducing the queues between a plant and a supervisor such that the 
interaction between the output channels of both plant and supervisor with 
their corresponding queues are hidden (see Figure 3(c)). 

M4. introducing the queues between a plant and a supervisor such that the 
interaction between the input channels of both plant and supervisor with 
their corresponding queues are hidden (see Figure 3(d)). 

Note that the above indices Ml, M2, M3, and M4 arc important as they will be 
used while presenting the results obtained from all the three case studies. 

To study an asynchronous interaction between a plant and a supervisor we 
present the work-flow shown in Figure 4, which checks whether the synchronous 
and the asynchronous implementation of a plant and a supervisor are equivalent. 
We check for both branching bisimulation equivalence and weak trace equiva- 
lence between the two closed loop systems. Our approach assumes that a plant 
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(a) Construction method, Ml. 




(b) Construction method, M2. 
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(c) Construction methods, M3. 
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(d) Construction methods, M4. 

Figure 3: Different ways to construct an asynchronous closed loop system. 
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model and a requirement model are given as automata. The tool Supremica [2] 
is used to synthesise the supervisor for a given plant and a given requirement 
model. The synthesised automaton is then converted into a process algebraic 
model in TCP language. Similarly the plant automaton model is also converted 
into a process algebraic model. This conversion of automaton models into pro- 
cess models is done manually, indicated by the dashed lines (Figure 4) . Finally, 
the tool-set mcrl2 [1] is used to check for the branching bisimulation relation 
between a synchronous closed loop and an asynchronous closed loop system de- 
signed by each construction method. The following case studies are modified in 
this report under asynchronous setting: 

1. Two machines and a buffer example. 

2. Pusher-lift system. 

3. Pneumatic cylinder. 

For each of the case studies we follow the work-flow as presented. In the next 
subsections we first introduce the three case studies, and in the last subsec- 
tion 3.4 we present the overall results obtained in a table. The mCRL2 specifi- 
cation for all the three case studies can be found in Appendix A,B,C. 



3.1 Two machines and a buffer example. 

This case study is adapted from the examples given in the Supremica tool set [2] . 
The case study consists of two machines which are connected through a buffer. 
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Figure 5: Two machines and a buffer example. 
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The control task is to synthesise a supervisor which controls the two machines 
such that the requirement is met, see Figure 5(b). The plant models are shown in 
Figure 5(a), the requirement model in Figure 5(b) and the synthesised supervisor 
in Figure 5(c). Note that the synchronous closed loop system for this case study 
is isomorphic to the supervisor transition system, except for the naming of the 
action labels. The action labels in a closed loop system will have ? symbol, while 
in a supervisor process they will be annotated with cither ? or !. 

The asynchronous system contained finitely many states and the results per- 
taining to this case study are shown in Figure 12. 

3.2 Pusher-lift system [14] 

The pusher lift system is a case study taken from a set of lecture notes on 
supervisory control course [14]. The overall system consists of a lift that can 
go up and down, a pusher that can retract and extend, and a product holder 
(see Figure 6(a)). The plant model of the lift is shown in Figure 6(c), pusher 
and product holder models in Figure 6(b), and the different requirements are 
shown in Figure 7. The synthesised supervisor model using the Supremica tool 
is shown in Figure 8. Note that the synchronous closed loop system for this 
case study is also isomorphic to the supervisor transition system, except for the 
naming of the action labels. 

The asynchronous closed loop system composed by all the four construction 
methods contained a deadlock for this case. Further analyzing the asynchronous 
closed loop system it was identified that the cause of the deadlock was a self 
loop in the plant model. This situation is explained by the following example 
in Figure 9 where a plant, a supervisor and a synchronous closed loop is given. 

When the asynchronous closed loop system is designed with the construction 
method Ml, the following trace indicated the deadlock: < h\1a\ ■ h 3 la 3 ■ h<fl.ai ■ 
h'fl.ai -fiilai -/i3?a 3 > as the transition klb is not possible. Note that in the above 
trace the actions decorated with will be performed by plant model. More- 
over, the removal of self loop (ft.2?a2) does not affect the synchronous closed loop 
system and then the above trace will not be valid for the modified asynchronous 
closed loop. 

Note that the results obtained for all the construction methods are shown in 
Figure 12 with respect to both, modified plants (i.e. plant models without self 
loops) and original plants. 

3.3 Pneumatic cylinder [14] 

The task in this case study is to design a supervisor that makes a cylinder 
move out when a push button is activated. Pushing the button will start the 
extending movement and releasing the button will start the retracting movement 
(sec Figure 10). The control signals ci and co are used to make the cylinder move 
in and out. The detection of the cylinder being at its innermost (outermost) 
position is realized through sensor psi (pso). The plant and requirement models 
are shown in Figure 11(a). The synthesised supervisor is shown in Figure 11(b). 
Note that the transition system of synchronous closed loop system is again 
isomorphic to supervisor model, except for the action labelling. 
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Figure 6: Plant models for Pusher-lift system. 
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Figure 7: Requirement models for Pusher-lift system. 
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Supen'isor Closed loop 

mode! 

Figure 9: Deadlock caused by the self loop. 
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Figure 10: Schematic diagram of pneumatic cylinder [14]. 
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(a) Plant and requirement models for Pneu- 
matic cylinder. 




(b) Synchronous closed loop model (Supervisor model) for 
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Figure 11: Pneumatic cylinder case study models. 
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Figure 12: Results obtained from all the case studies. 



In this case all the asynchronous closed loop systems designed by different meth- 
ods were containing infinitely many states. To further analyse this system, all 
the asynchronous closed loop systems were redesigned with 1 place queues. The 
results pertaining to all the construction methods are shown in Figure 12. 



3.4 Results 

In this subsection we present the results obtained for all the three case-studies in 
the Figure 12. The following are the key observations found in the table shown 
in Figure 12. We use the phrase 'positive result' to mean that synchronous 
closed loop system is equivalent to asynchronous one. 

• The construction method Ml yielded positive result for the all case studies 
with respect to weak trace equivalence. 

• In the modified pusher lift case study, only Ml and M3 yielded positive 
result under weak trace equivalent even though the asynchronous closed 
loop system constructed by Ml was branching bisimilar to synchronous 
one. 

• The toy example case study had positive results for all the construction 
methods. 

The construction method Ml satisfied the most number of case studies under 
weak trace and branching bisimulation equivalence. This makes Ml a suitable 
candidate to further study and answer our research question. 



4 Discussion 



In this section we sketch the conditions for a synchronous closed loop system 
to be desynchronisable. A synchronous closed loop system is called desynchro- 
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nisablc iff it is branching bisimilar to the corresponding asynchronous closed 
loop system. These conditions are important as they prevent the constructed 
asynchronous closed loop system from deadlocks and generation of infinitely 
many states. Before we give these conditions formally we need some auxiliary 
definitions. First, we ask the reader to recall the definitions of transition system 
of a process, and a synchronous closed loop system as defined in Section 2.1. 

Let rj : Qc — > 2 X be a function which returns a set of enabled actions at a 
state in a synchronous closed loop system C, i.e. T]{qc) — {& \ Qc ~ ° L ^}> where 
qc eR,«el Let Br : 1Z — > N be a function defined as Br(g c ) = |f7(g c )|, 
which is used to access the degree of branching at a state. 

Furthermore, we partition the set X (defined in Section 2.1) into two disjoint 
subsets lp,Tp with respect to the given plant process P as: 

• T P = {hla | hla e I A h € inch(P)}. 

• X° P = {kla | kla e T A k e outch(P)}. 

The following conditions are sufficient for desynchronisability: 

1. Plant and supervisor composition must be well posed. This term is bor- 
rowed from [5] where it was used for similar purpose, i.e. to ensure the 
asynchronous closed loop system is deadlock free. Consider the transition 
system Tp = (Qp,^p,q P ,B) for a plant process P. Similarly consider 
Ts as the transition system of a supervisor process S with T§ = (Qs, — >s 
,q i s ,B). Let N : B* -» B* be a function defined as: N(hla.s) = h\a.N(s) 
and N(hla.s) — hla.N(s) for some sequence stB*, and the dot symbol 
(.) indicates the concatenation of the sequence. Then, the plant and su- 
pervisor composition is called well posed iff the following conditions are 
satisfied: 

\/seB*,h\aeA.[q P ^pq P — > P => q s ^ S Qs — >s] A 

VseB ,h\aeA.[q s ^»s qs — >s => q P — » p 9p — >pJ- 

For example, consider a plant process P = /i!a • lie ■ P + k\b ■ and a 
supervisor process S = hla-l\c-S. It is easy to verify that the synchronous 
closed loop system is deadlock free, as 9g(P || S) = hla ■ lie ■ 8b{P \\ S). 
But when asynchronous closed loop system is designed using construction 
method Ml it will deadlock, because the plant can reach a deadlock state 
(0) by performing an action k\b. 

2. No self loops in either plant model or supervisor model, i.e. both plant 
and supervisor should not contain a state such that a transition from that 
state lead into that same state. Let Tp,Ts be the transition system for a 
plant and a supervisor, respectively Then, Tj must satisfy the condition 

Va e Brf q 3 G Qj\qj qj] for j e {P, S}. 

The need of this condition was explained with an example in Pusher-lift 
case study (Section 3.2), which resulted in a deadlocked state in asyn- 
chronous closed loop system even though the synchronous closed loop 
system was deadlock free. 



17 



Figure 13: Important property for desynchronisability. 




Figure 14: Cycles containing only controllable actions causes infinite states. 



All the states in a transition system for closed loop system must satisfy 
the diamond property (see Figure 13). Let Tq be a transition system of 
a synchronous closed loop system C. Then Tq is said to satisfy diamond 
property iff the following condition holds 

Vo, b € l,q,qi,q 2 € Qc- q -^-> qi A q — > 92 => 3? 3 .[gi — > <? 3 A q 2 ? 3 ] 

This condition is required for establishing a branching bisimulation rela- 
tion between a synchronous and an asynchronous closed loop system. 

All the cycles from the initial state in a synchronous closed loop system 
must have at least one controllable, and one uncontrollable action in that 
cyclic trace. Again let Tc be a transition system of a synchronous closed 
loop system. Then, 



Vtt el* 



<7c^» 1c (irn2> ^ 0) A (?rnZ£ 7^ 



Note, that we abuse the notation xDA to denote the set of elements that 
occur both in the sequence x and the set A. Intuitively, this condition 
ensures the progress of the components (i.e. plant and supervisor) in 
an asynchronous interaction. Consider the following example where P — 
(k?b ■ h?a + h?a ■ k?b) ■ P and S = (Mb ■ h\a + h\a ■ k\b) ■ S. It is clear to see 
that d B (P || S) = (klb-hla + hla-m)-d B (P\\ S), and there existsacycle 
of actions [hla- klb)* such that all actions are controllable actions. In this 
case the asynchronous closed loop system will have infinite states because 
supervisor S can always send the controllable actions Mb, or hla to the 
unbounded queue, and the plant can wait forever to remove these actions 
from the queue (see Figure 14). In figure 14 the two states with triangles 
indicate that the transitions from these two states are same as that of the 
black state. A similar example can also be given in which cycles contain 
only uncontrollable actions. 
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Note that the formal proof of the above fact is under construction and will be 
published in future. 

A Final Remark. The transition systems generated by the four methods 
from a synchronous closed loop system are always isomorphic to each other 
apart from the difference in abstraction of actions. A hypothesis which one 
would expect to hold is that, all the four construction methods should always 
yield an equivalent asynchronous closed loop systems at least modulo weak 
trace equivalence. But the results shown in the Figure 12 implies that the 
above hypothesis is not true in general and the abstraction of actions does 
matter while reducing a transition system (the asynchronous one) even modulo 
weak trace equivalence. We conclude this report by framing the following open 
question namely, "which of the construction methods classify a larger class of 
desynchronisable closed loop system with respect to an equivalence relation?" 
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A mCRL2 model for two machine and a buffer 
example 

nnnnranindex for action namesr/.r/x/.rar/.ra 

nil = loadl 
7.7.12 = load2 
7.7.ull= unloadl 
7.7.ul2= unload2 

0/0/0/0/0/0/0/0/0/0/0/0/ 0/ 0/0/0/ 0/ 0/ 0/0/0/ 0/ 0/ 0/0/0/ 0/ 0/0/0/0/0/0/0/0/0/ 0/ 0/0/0/ 0/ 0/ 0/0/0/ 0/ 0/ 0/ 0/ 
/o/o/o/o/o/o/o/o/o/o/o/o/o/o/o/o/o/o/o/o/o/o/o/o/o/o/oA 

act 

s_ll,r_ll,s_ll' ,r_ll' ,c_ll,c_ll' ,s_12,r_12,s_12' ,r_12' ,c_12,c_12' , 
s_ull,r_ull,s_ull' ,r_ull' , c_ull , c_ull ' ,s_ul2,r_ul2,s_ul2' ,r_ul2' , c_ul2 , c_ul2 ' ; 

proc 

Ml=r_ll' .s_ull' .Ml; 
M2=r_12' .s_ul2> .M2; 

7,Ml=r_ll' .s_ull.Ml; 
7.M2=r_12' .s_ul2.M2; 

S0=s_ll.S4; 
S4=r_ull.Sl; 
Sl=s_12.S2;7. 
S2=r_ul2.S0 + s_ll.S5; 
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S5=r_ul2.S4 + r_ull.S3; 
S3=r_ul2.Sl; 

'/.S0=s_ll.S4; 
°/,S4=r_ull ' .SI; 
7„Sl=s_12.S2; 

%S2=r_ul2 ' . SO + s_ll.S5; 
7.S5=r_ul2' .S4 + r_ull'.S3; 
7 S3=r_ul2 ' . SI ; 

QlKxl: Int) = (xl==0)-> r_ll . Qll (xl+1) <> 
(s_ll' .Qll(xl-l) + r_ll.Qll(xl+l)) ; 

Q12(x2: Int) = (x2==0)-> r_12.Q12(x2+l) <> 
(s_12> .Q12(x2-1) + r_12.Q12(x2+D) ; 

QulKuxl: Int) = (uxl==0)-> r_ull ' . Qull (uxl+1) <> 
(s_ull.Qull(uxl-l) + r_ull' .Qull (uxl+1) ) ; 

Qul2(ux2: Int) = (ux2==0)-> r_ul2' .Qul2(ux2+1) <> 
(s_ul2.Qul2(ux2-l) + r_ul2' . Qul2(ux2+1) ) ; 

Plant=Ml I I M2 ; 
Supervisor=SO; 

init 

hide({c_ll' ,c_12> ,c_ull' ,c_ul2'}, 

allow({c_ll,c_12,c_ull,c_ul2,c_ll' ,c_12\c_ull' ,c_ul2'}, 

comm({s_ll I r_ll->c_ll , s_12 I r_12->c_12 , s_ull I r_ull->c_ull , 
s_ul2 I r_ul2->c_ul2 , s_ll ' I r_ll > ->c_ll ' , s_12 ' I r_12 ' ->c 
s_ull ' I r_ull ' ->c_ull ' , s_ul2 ' I r_ul2 ' ->c_ul2 ' } , 
Plant I IQII(O) I |Q12(0) I I Qull (0) I |Qu12(0) I I Supervisor 



B mCRL2 model for Pusher-lift case study. 

y.nr/.y.Index for action name s°/.°/X/.n 

TL asc=ascended 

7«°/o desc=descended 

•/.'/. d0=down0 

7.°/. dl=downl 

77o ext=extended 

77o ret=retracted 

7.7. pll=placel 

7.7. pld=placed 

7.7. pu0=push0 

7.7. pul=pushl 

7.7. up0=up0 

7.7. upl=upl 
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01 61 01 01 01 61 61 01 01 01 61 01 01 010161 01 01 010161 01 01 010161 01 01 010161 01 01 01 
16 10 10 16 16 10 10 10 16 16 1010 10 16 tO /O 10 16 16 fo 10 10 16 16 lo 10 10 16 /o/o/o/o/o/O 



act 

s_asc,r_asc,s_asc' ,r_asc' , c_asc , c_asc ' , s_desc ,r_desc , s_desc ' ,r_desc' , 
c_desc,c_desc' ,s_dO,r_dO,s_dO' ,r_dO' ,c_dO,c_dO' ,s_dl,r_dl,s_dl' ,r_dl' , 
c_dl,c_dl' , s_ext,r_ext,s_ext' ,r_ext' , c_ext , c_ext ' , s_pll,r_pll,s_pll' , 
r_pll' , c_pll , c_pll ' ,s_pld,r_pld,s_pld' ,r_pld' ,c_pld,c_pld' , s_puO ,r_puO , 
s_puO ' ,r_puO ' , c_puO , c_puO ' , s_pul ,r_pul , s_pul ' ,r_pul ' , c_pul , c_pul ' , s_ret , 
r_ret , s_ret ' , r_ret ' , c_ret , c_ret ' , s_upO , r_upO , s_upO ' , r_upO ' , c_upO , c_upO ' , 
s_upl , r_upl , s_upl ' , r_upl ' , c_upl , c_upl ' ; 

proc 

Pul=r_puO' .Pul+r_pul' .Pu2; 
Pu2=s_ext' .Pu3; 
Pu3=r_pul ' . Pu3 + r_puO'.Pu4; 
Pu4=s_ret' .Pul; 

°/.L0001=r_dO . L0001+r_up0 . L0001+r_upl . L1001+r_dl . L0101 ; 
L0001=r_upl> .L1001+r_dl' .L0101; 

L1001=s_asc' .L1010; 

7,L1010=(r_upl+r_dO) .LIOIO + r_upO . L0010+r_dl . L1110 ; 
L1010=r_up0' .L0010+r_dl' .LlllO; 

°/„L1110=(r_upl+r_dl) .LlllO + r_dO.L1010 + r_upO.L0110; 
L1110=r_dO' .LIOIO + r_upO' .LOllO; 

7.L0010=(r_upO+r_dO) .LOOIO + r_upl.L1010 + r_dl.L0110; 
L0010=r_upl' .LIOIO + r_dl'.L0110; 

L0110=s_desc' .LOlOl; 

7„L0101=(r_upO+r_dl) .LOlOl + r_dO.L0001 +r_upl . L1101 ; 
L0101=r_dO' .LOOOl +r_upl ' . L1101 ; 

7„L1101=(r_upl+r_dl) .L1101 + r_upO . L0101+r_dO . LlOOl ; 
L1101=r_upO' .L0101+r_dO' .LlOOl; 

Prl=r_pll' .Pr2; 
Pr2=s_pld' .Prl; 

7„QpuO(puO: Int) = (puO==0)-> r_puO.QpuO(puO+l) <> 
7, (s_puO' .QpuO(puO-l) + r_puO.QpuO(puO+D) ; 

y.QpuKpul: Int) = (pul==0)-> r_pul . Qpul (pul+1) <> 
7. (s_pul' .QpuO(pul-l) + r_pul. Qpul (pul+1) ) ; 

S0=s_dl.Sll+s_pll.S22; 
Sll=s_pll.S9; 
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S22=s_dl.S9 + r_pld.S23; 

S9=r_pld.S12; 

S23=s_dl.S12; 

S12=s_upl.S8 + s_dO.S24; 

S8=s_dO.S21; 

S24=s_upl.S21; 

S21=r_asc.S2; 

S2=s_pul.S4; 

S4=r_ext.S6; 

S6=s_dl . S18+s_up0 . S10+s_puO . S3 ; 

S18=s_upO.S20 + s_puO.S15; 

S10=s_dl.S20 + s_puO.S7; 

S3=s_dl . S15+s_up0 . S7+r_ret . SI ; 

S20=r_desc . S16+s_pu0 . S19 ; 

S15=s_upO.S19+ r_ret.S14; 

S7=s_dl . S19+r_ret . S5 ; 

Sl=s_dl . S14+s_up0 . S5 ; 

S16=s_puO.S13; 

S19=r_desc . S13+r_ret . S17 ; 

S14=s_upO.S17; 

S5=s_dl.S17; 

S13=r_ret.Sll; 

S17=r_desc.Sll; 

QpuO(xl: Int) = (xl==0)-> r_puO . QpuO (xl+1) <> 
(s_puO' .QpuO(xl-l) + r_puO. QpuO (xl+1) ) ; 

Qpul(x2: Int) = (x2==0)-> r_pul . Qpul (x2+l) <> 
(s_pul' .Qpul(x2-1) + r_pul.Qpul(x2+D) ; 

Qext(x3: Int) = (x3==0)-> r_ext ' . Qext (x3+l) <> 
(s_ext.Qext(x3-l) + r_ext ' . Qext (x3+l) ) ; 

Qret(x4: Int) = (x4==0)-> r_ret ' . Qret (x4+l) <> 
(s_ret.Qret(x4-l) + r_ret ' . Qret (x4+l) ) ; 

Qd0(x5: Int) = (x5==0)-> r_dO.QdO(x5+l) <> 
(s_dO> .Qd0(x5-1) + r_dO.QdO(x5+D) ; 

Qdl(dl: Int) = (dl==0)-> r_dl . Qdl (dl+1) <> 
(s_dl> .Qdl(dl-l) + r_dl.Qdl(dl+D) ; 

QupO(upO: Int) = (upO==0)-> r_upO.QupO(upO+l) <> 
(s_upO' .QupO(upO-l) + r_upO.QupO(upO+D) ; 

QupKupl: Int) = (upl==0)-> r_upl . Qupl (upl+1) <> 
(s_upl' .Qupl(upl-l) + r_upl. Qupl (upl+1) ) ; 

Qasc(x6: Int) = (x6==0)-> r_asc' .Qasc(x6+1) <> 
(s_asc . Qasc (x6-l) + r_asc' .Qasc(x6+1)) ; 
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Qdesc(x7: Int) = (x7==0)-> r_desc ' . Qdesc (x7+l) <> 
(s_desc.Qdesc(x7-l) + r_desc '. Qdesc (x7+l) ) ; 

QplKpll: Int) = (pll==0)-> r_pll.Qpll(pll+l) <> 
(s_pll> .Qpll(pll-l) + r_pll.Qpll(pll+l)) ; 

QpldCpld: Int) = (pld==0)-> r_pld' . Qpld(pld+1) <> 
(s_pld.Qpld(pld-l) + r_pld' . Qpld(pld+1) ) ; 

Plant=Pul| IL0001I |Prl; 
Supervisor=SO; 

init 

7o°/.For asynchronous closed loop system. 

hide({c_asc' ,c_desc' ,c_dO' ,c_dl' ,c_ext' ,c_pll' , c_pld' , c_pu(V , c_pul' ,c_ret' , 
c_upO ' , c_upl ' } , 

allow ({c_asc , c_desc , c_dO , c_dl , c_ext , c_pll , c_pld , c_puO , c_pul , c_ret , c_upO , c_upl , 
c_asc' ,c_desc' , c_dO' , c_dl' ,c_ext' , c_pll' ,c_pld' , c_puO' , c_pul' ,c_ret' , 
c_upO ' , c_upl ' } , 

comm({s_asc I r_asc->c_asc , s_desc I r_desc->c_desc , s_dO I r_dO->c_dO, s_dl I r_dl->c_dl , 
s_ext I r_ext->c_ext , s_pll I r_pll->c_pll , s_pld I r_pld->c_pld, 
s_puO I r_puO->c_puO , s_pul I r_pul->c_pul , s_ret I r_ret->c_ret , 
s_upO I r_upO->c_upO , s_upl I r_upl->c_upl , 

s_asc ' I r_asc ' ->c_asc ' , s_desc ' I r_desc ' ->c_desc ' , s_dO ' I r_dO ' ->c_dO ' , 
s_dl ' I r_dl ' ->c_dl ' , s_ext ' I r_ext ' ->c_ext ' , s_pll ' I r_pll ' ->c_pll ' , 
s_pld' |r_pld'->c_pld' ,s_puO' |r_puO'->c_pu(V ,s_pul' I r_pul ' ->c_pul ' , 
s_ret ' I r_ret ' ->c_ret ' , s_upO ' I r_upO ' ->c_upO ' , s_upl ' I r_upl ' ->c_upl ' } , 
(Plant I I Supervisor | | Qasc (0) I I Qdesc (0) I I QdO (0) I I Qdl (0) I I Qext (0) I I Qpll (0) I I 
Qpld(0) I |QpuO(0) I iQpul(O) I |Qret(0) I iQupO(O) I |Qupl(0)) 

))); 

7,7, For synchrnous closed loop system. 

7 allow ({c_asc , c_desc , c_dO , c_dl , c_ext , c_pll , c_pld , c_puO , c_pul , c_ret , c_upO , c_upl} , 
7 comm({s_asc I r_asc->c_asc , s_desc I r_desc->c_desc, s_dO I r_dO->c_dO , s_dl I r_dl->c_dl , 
7. s_ext I r_ext->c_ext ,s_pll I r_pll->c_pll , s_pld | r_pld->c_pld, s_puO I r_puO->c_puO , 

7. s_pul I r_pul->c_pul ,s_ret I r_ret->c_ret , s_upO I r_upO->c_upO, s_upl I r_upl->c_upl> , 

7oPlant I I Supervisor 
7.)); 

C mCRL2 model for the Pneumatic cylinder 

act 

s_13,r_13,s_13' ,r_13' ,c_13,c_13' ,s_14,r_14,s_14' ,r_14' ,c_14,c_14' ,s_16,r_16, 

s_16' ,r_16' ,c_16,c_16' , s_23 ,r_23 , s_23 ' ,r_23' ,c_23,c_23' ,s_24 ) r_24,s_24' , 

r_24' ,c_24,c_24' ,s_25,r_25,s_25' ,r_25' ,c_25,c_25' ,s_26,r_26,s_26' ,r_26' ,c_26,c_26' ; 

proc 

P0=r_13' .PI; 
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Pl=(s_14'+s_16') .PO; 

Q0=r_23' .Ql; 
Ql=r_25> .Q3+s_24' .Q2; 
Q2=r_25' .Q3; 
Q3=s_26> .Q0+r_23> .Ql; 

Plant=PO| IQO; 

7 Note that for this case study 1 place queues are used 
'/.Because unbounded queues cause infinite states asynch 
"/.closed loop system. 

Q13(xl3: Int) = (xl3==0)-> r_13.Q13(xl3+l) + 
(xl3==l)-> (s_13' .Q13(xl3-1) + r_13.Q13(xl3+D); 

Q14(xl4: Int) = (xl4==0) -> r_14' . Q14(xl4+1)+ 
(xl4==l) ->( s_14.Q14(xl4-l)+r_14' .Q14(xl4+D) ; 

Q16(xl6: Int) = (xl6==0) -> r_16 ' . Q16 (xl6+l) + 
(xl6==l) -> (s_16.Q16(xl6-l)+r_16' .Q16(xl6+D) ; 

Q23(x23: Int) = (x23==0)-> r_23.Q23(x23+l) + 
(x23==l)->( s_23' .Q23(x23-l)+r_23.Q23(x23+D) ; 

Q25(x25: Int) = (x25==0)-> r_25 . Q25 (x25+l) + 
(x25==l)->( s_25' .Q25(x25-l)+r_25.Q25(x25+D) ; 

Q24(x24: Int) = (x24==0) -> r_24' . Q24(x24+1) + 
(x24==l) -> (s_24.Q24(x24-l)+r_24' .Q24(x24+D) ; 

Q26(x26: Int) = (x26==0) -> r_26' .Q26(x26+1) + 
(x26==l) ->(s_26.Q26(x26-l)+r_26' . Q26(x26+1) ) ; 

S0=s_13.Sl; 

Sl=r_14.S0 + r_16.S2; 

S2=s_23.S3; 

S3=s_13.S4+r_24.S5; 

S4=r_16.S3 +r_14.S6+ r_24.S7; 

S5=s_13.S7; 

S6=r_24.S8+s_25.S9; 

S7=r_16.S5+r_14.S8; 

S8=s_25.S9; 

S9=s_13.S10+r_26.S0; 

S10=r_16.Sll + r_26.Sl + r_14.S9; 

Sll=r_26.S2 + s_23.S3; 

Supervisor=SO; 
init 

7«For asynchronous closed loop system 
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hide({c_13' ,c_14' ,c_16' ,c_23' ,c_24\c_25> ,c_26'}, 

allow({c_13,c_13> ,c_14,c_14' ,c_16,c_16' ,c_23,c_23' ,c_24,c_24> ,c_25, 
c_25' ,c_26,c_26>}, 

comm({s_13|r_13->c_13,s_13' |r_13'->c_13' ,s_14|r_14->c_14,s_14' |r_14'->c_14' , 
s_16|r_16->c_16,s_16' I r_16 ' ->c_16 ' ,s_23|r_23->c_23,s_23> |r_23'->c_23' , 
s_24|r_24->c_24,s_24' |r_24>->c_24' , s_25 I r_25->c_25 , s_25 > |r_25'->c_25' , 
s_26 I r_26->c_26 , s_26 ' I r_26 ' ->c_26 ' } , 
Plant I |Q13(0) I IQ14C0) I |Q16(0) I |Q23(0) I |Q24(0) I |Q25(0) I |Q26(0) I I Supervisor 

))) 

°/o°/o For synchronous closed loop sytem 

7,allow({c_13 , c_14 , c_16 , c_23 , c_24 , c_25 , c_26} , 

7, comm({s_13 I r_13->c_13, s_14 I r_14->c_14, s_16 I r_16->c_16, 

7, s_23 I r_23->c_23 , s_24 I r_24->c_24 , s_25 I r_25->c_25 , 

7. s_26|r_26->c_26}, 

7. Plant I I Supervisor 

7. ))*/. 

7. ; 
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